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TITLE: JUST-IN-TIME SERVICES FOR SMALL FOOTPRINT DEVICES 

BACKGROUND OF THE INVENTION 
Field of the Invention 

5 The present invention relates to the field of resource-constrained small footprint devices such as 

handheld computers, personal data assistants (PDAs), cellular phones, etc. More particularly, the present 
invention comprises a lightweight framework supporting shareable services in small footprint devices. 
Description of the Related Art 

The field of "smart" small footprint devices is growing and changing rapidly. Small footprint devices 
10 include handheld computers, personal data assistants (PDAs), cellular phones, global positioning system (GPS) 
receivers, game consoles, and many more such devices. These devices are becoming more intelligent and 
interconnected. Technologies such as Jini™ from Sun Microsystems, Inc. and initiatives such as the Open 
Service Gateway Initiative (OSGI) are expanding the traditional concepts of computer networks to include small 
footprint devices. 

15 This increased device interconnection has introduced a need for both new types of computing services 

and new ways to integrate computing services, both inter-device-based and intra-device-based services. A 
"service" is an entity implemented within or accessible from a device that can be used by a person, an application, 
or another service. The concept of a service is broad and can be considered at many different scales. For 
example, services include familiar network-based services such as shared printing, email, telephony, etc. Services 

20 also include less familiar examples such as an energy management service which may control the power 
consumption of devices within a local network, a diagnostic service which allows a device to send information to 
a service technician when an error occurs, a health-monitoring service which immediately notifies health 
professionals of an emergency, etc. 

Services also include modules or applications located and executable within a local machine or device. 

25 For example, local application programs may utilize a calendar service, a contact list service, a bookmark service, 
etc. In this example, an application program may use these services together to allow a user to select a person 
from the contact list, record an appointment time for a meeting with the person, and create a bookmark for easy 
access to the appointment entry. 

It is becoming more common today to execute multiple services and applications together in a single 

30 small footprint device. However, since memory, processing power, and other resources are typically very limited 
in small footprint devices, a specialized lightweight software framework is necessary to achieve the desired 
integration of services and applications. It is also desirable that the framework be flexible and extendable enough 
to provide support for any types of services and applications for any kind of small footprint device. A further 
goal may be that the framework be compatible and integrated with off-device services such as services available 

35 to devices in a Jini™ network. A lightweight, extendable containment framework for applications/services 
running on a small footprint device is described herein. 

SUMMARY OF THE INVENTION 

The present invention comprises a system and method to contain and manage program modules in a 
40 small footprint device. As used herein, a module is an executable software component The invention comprises 
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a containment framework for shareable modules. One embodiment of this containment framework is referred to 
as York 1.1. The containment framework enables module registration, lookup, instance tracking, etc. Modules in 
the containment framework may be used by other modules as services. The containment framework may be 
dynamic, allowing modules to be registered and loaded as desired or needed. 
5 Modules may be grouped into parcels and managed as a unit Parcels may serve several purposes. For 

example, much of a module's runtime context may be determined by the parcel from which it originates. Also, 
applications may be managed by parcel, including installation and upgrade procedures. Also, the parcel system 
enables the support of multiple target development (i.e., development groups may use parcels to develop for 
different platforms or systems simultaneously without breaking reliance on common libraries). 

10 As described above, a containment framework for a small footprint device should be lightweight. Hie 

present containment framework is able to function on a device with very little memory. For example, in one 
embodiment the containment framework may function on a device with only 300KB writeable memory and still 
leave enough memory space for several modules to operate. In addition, the containment framework may be 
responsive on devices with low processing power, such as small footprint devices with 16MHz-class chips. 

15 One aspect of the containment framework which aids in achieving its lightweight status is that it is a 

non-hierarchical framework. Hierarchical containment can be a very useful feature in a framework, providing a 
standard way to group modules and allow them to discover and use each other's services. However, hierarchical 
containment is generally expensive to achieve in terms of the resources required to implement it The present 
containment framework provides many of the advantages associated with a hierarchical framework, without the 

20 usual overhead. Modules may intercept module lookup requests by other modules, thereby allowing them to 
customize the requesting module's environment 

The containment framework may be based on common standards. For example, in one embodiment, the 
containment framework may be written in pure Java™ and may be fully compliant with and executed in the 
Personal Java™ 3.0 application environment PersonalJava™ is a Java™ application environment specifically 

25 designed for consumer devices for home, office, and mobile use. It comprises the Java™ virtual machine (JVM) 
and a subset of the Java™ Application Programming Interface (API), including core and optional APIs and class 
libraries. In addition, the PersonaUava™ API includes specific features required by consumer applications in 
resource-limited environments. It is noted that the containment framework may also be comprised in hardware 
ROM or be compiled into native code. 

30 Because the containment framework may be based on common standards, it may be ported easily to 

different device types and to devices made by different vendors, which greatly reduces time-to-market and 
development costs. The extendable architecture of the framework may also allow new modules to be introduced 
into the framework as needed or desired for different devices or services. The architecture may also allow for 
customizable and scaleable user interfaces. For example, the user interface component of an application may be 

3 5 swapped out as appropriate to the display type for different devices. 

As described in more detail below, the containment framework maintains a list of loaded modules, as 
well as related system data. Modules normally access the module list or the system data only indirectly, e.g., by 
calling methods of a central framework instance. However, certain modules, referred to as system modules, may 
have the ability to access or modify the system data themselves. This type of direct data access to core data helps 
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to keep the containment framework lightweight Since system modules have access to the core system data, any 
necessary or desired extended functionality beyond the basic module management performed by the central 
framework instance may be introduced to a system by adding an appropriate system module. Thus, the 
containment framework is also highly extendable. 
5 A system may comprise a set of core service modules available for other modules to use. These core 

services may include services such as the calendar, contact list, and bookmark services described in an example 
above. Together with such core services, the containment framework provides a complete architecture for 
running an integrated suite of applications and services on a small footprint device. For example, the Personal 
Applications suite available from Sun Microsystems, Inc. is built around one embodiment of the containment 
10 framework. The Personal Applications suite comprises an integrated set of compact, memory-efficient 
applications, including the Personal Applications Browser, the Persona] Applications Email Client, and the 
Personal Organizer. 

Although the system and method of the present invention may be associated with managing modules 
running on a small footprint device, it is noted that they are not limited to this use. To the contrary, many aspects 
15 of the present invention may be useful in systems that do not have such a large resource constraint. On the other 
hand, embodiments of the containment framework may be designed so that they are easily transferable to 
environments with an even greater constraint in resources than the small footprint devices described above. For 
example, an embodiment of the containment framework may run in an EmbeddedJava™ application environment 
with little or no modification. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other objects and advantages of the invention will become apparent upon reading the following detailed 
description and upon reference to the accompanying drawings in which: 

Figure 1 is a block diagram illustrating the hardware architecture of a typical small footprint device; 
25 Figure 2 illustrates a typical hierarchy of hardware/software layers involved in a system running 

applications and services within the containment framework; 

Figure 3 illustrates an exemplary network in which a small footprint device running applications/services 
in the containment framework is connected to a local service-based network; 

Figure 4 illustrates the discovery process, in which a service provider finds a lookup service; 
30 Figure 5 illustrates the join process, in which a service provider registers its service with a lookup 

service; 

Figure 6 illustrates the lookup process, in which a client requests a service from a lookup service; 

Figure 7 illustrates the service invocation process, in which a client invokes a service using a service 
object received from a lookup service; 
35 Figure 8 is an abstract block diagram illustrating the basic architecture of the containment framework; 

Figures 9 and 10 illustrate the use of module request listeners in the containment framework to simulate 
a hierarchical containment environment; 

Figure 1 1 illustrates the use of parcels to group modules together, 
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Figure 12 is a flowchart diagram illustrating a typical lookup process that the central framework instance 
may perform when it receives a lookup request for a service module from a client module; and 
Figure 13 is a flowchart diagram illustrating the module release process. 

While the invention is susceptible to various modifications and alternative forms, specific embodiments 
5 thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, 
however, that the drawings and detailed description thereto are not intended to limit the invention to the particular 
form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling 
within the spirit and scope of the present invention as defined by the appended claims. 

10 DETAILED DESCRIPTION OF THE INVENTION 
Figure 1 - Hardware Architecture Block Diagram 

Figure 1 is a block diagram illustrating the hardware architecture of a typical small footprint device. As 
used herein, a small footprint device is a hardware device comprising computing resources such as a processor 
and a system memory, but having significantly greater constraints on one or more of these resources than a 

1 5 typical desktop computer has. For example, a small footprint device may have two megabytes of memory or less, 
whereas a typical desktop system may have 64 megabytes or more. Also a typical small footprint device may 
have significantly less processing power than a typical desktop computing system, either in terms of processor 
type, or processor speed, or both. For example, a personal data assistant device may have a 16 MHz processor, 
whereas a typical desktop system may have a processor speed of 100 MHz or higher. Also, a typical small 

20 footprint device may have a display size significantly smaller than the display screen of a desktop computing 
system. For example, the display screen of a handheld computer is typically small compared to the display screen 
of a desktop monitor. 

It is noted that the specific numbers given are exemplary only and are used for comparison purposes. 
For example, a personal data assistant having eight megabytes of memory or more may still be a small footprint 

25 device, although the device has more memory than the typical figure of two megabytes given above. 

Small footprint devices may also have constraints on other resource types compared to typical desktop 
computing systems, besides the memory, processor, and display size resources described above. For example, a 
typical small footprint device may not have a hard disk, may not have a network connection, or may have an 
intermittent network connection, or may have a wireless network connection, etc. 

30 Many small footprint devices are portable and/or are small compared to desktop computers, but are not 

necessarily so. Also, many small footprint devices are primarily or exclusively battery-operated. Also, small 
footprint devices may typically have a more limited or narrow range of usage possibilities than a typical desktop 
computing system. Small footprint devices include, but are not limited to, the following examples: handheld 
computers, wearable devices (e.g., wristwatch computers), personal data assistants (PDAs), "smart" cellular 

35 telephones, set-top boxes, game consoles, global positioning system (GPS) units, electronic textbook devices, etc. 
Since new classes of consumer devices are rapidly emerging, it is not possible to provide an exhaustive list of 
small footprint devices. However, the term "small footprint device" is intended to include such devices as may 
reasonably be included within the spirit and scope of the term as described above. 
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necessarily so. Also, many small footprint devices are primarily or exclusively battery-operated. Also, small 
footprint devices may typically have a more limited or narrow range of usage possibilities than a typical desktop 
computing system. Small footprint devices include, but are not limited to, the following examples: handheld 
computers, wearable devices (e.g., wristwatch computers), personal data assistants (PDAs), "smart*' cellular 

35 telephones, set-top boxes, game consoles, global positioning system (GPS) units, electronic textbook devices, etc. 
Since new classes of consumer devices are rapidly emerging, it is not possible to provide an exhaustive list of 
small footprint devices. However, the term "small footprint device" is intended to include such devices as may 
reasonably be included within the spirit and scope of the term as described above. 
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Figure 1 illustrates a block diagram of a typical small footprint device. It is noted that the small footprint 
device may have various different architectures, as desired. The hardware elements not necessary to understand 
the operation of the present invention have been omitted for simplicity. 

As shown in Figure 1, the small footprint device contains a processor 100. The processor 100 may be 

5 any of various types, including an x86 processor, e.g., a Pentium class, a PowerPC processor, as well as other less 
powerful processors or processors developed specifically for small footprint devices. The processor 100 may 
have various clock speeds, including clock speeds similar to those found in desktop computer-class processors, as 
well as lower speeds such as 16 MHz. 

Also shown in Figure 1 the device includes a system memory 102. The system memory 102 may 

10 comprise memory of various types including RAM or ROM. A typical small footprint device may have a very 
small memory storage capacity compared to a typical desktop computer system. 

A small footprint device may also comprise one or more input mechanisms. An input mechanism 104 is 
illustrated in Figure 1. The input mechanism 104 may be any of various types, as appropriate to a particular 
device. For example, the input mechanism may be a keypad, mouse, trackball, touch pen, microphone, etc. 

15 a small footprint device may also comprise one or more display mechanisms. A display 106 is 

illustrated in Figure 1. However, a small footprint device may not comprise a display, or may comprise another 
type of output mechanism, such as an audio speaker. The display mechanism 106 may be any of various types, as 
appropriate to a particular device. The display mechanism for a typical small footprint device, such as a smart 
cellular phone, may be small compared to the display of a desktop computer system. 

20 Figure 2 - Hardware/Software Hierarchy Diagram 

Figure 2 illustrates a typical hierarchy of hardware/software layers involved in a system running 
applications and services within the containment framework. The drawing is exemplary, and various layers may 
be added, combined, or omitted as appropriate for a particular device or implementation. 

The base layer shown in Figure 2 is the device hardware layer 120, which comprises the hardware 

25 resources necessary to support a software system, such as a processor and system memory. In one embodiment, 
the hardware of a small footprint device, such as the small footprint device hardware example illustrated in Figure 
1, implements the hardware layer 120 illustrated in Figure 2. However, in other embodiments, the hardware layer 
120 may be implemented in other types of devices, such a device with even greater resource constraints than a 
typical small footprint device, such as a smart card. 

30 As shown in Figure 2, the next layer up from the hardware layer is the operating system layer 122. As is 

well known in the art, the operating system functions as an interface layer between the device hardware and 
software running on the device and serves as a manager for low-level tasks such as input/output, memory 
management, etc. The operating system 122 illustrated in Figure 2 may be any particular operating system which 
supports the higher layers shown in Figure 2. The operating system 122 may be a small and efficient one that is 

35 suitable for or written particularly for use in a small footprint device. For example, the operating system 122 may 
be the Java™OS operating system available from Sun Microsystems, Inc. 

In one embodiment, the containment framework is implemented in a Java™ application environment as 
one or more Java™ classes. As shown in Figure 2, the Java™ virtual machine layer 124 and Java™ application 
programming interface (API) class libraries layer 126 are the next layers up from the operating system. These 
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Figure 1 illustrates a block diagram of a typical small footprint device. It is noted mat the small footprint 
device may have various different architectures, as desired. The hardware elements not necessary to understand 
the operation of the present invention have been omitted for simplicity. 

As shown in Figure 1, the small footprint device contains a processor 100. The processor 100 may be 
5 any of various types, including an x86 processor, e.g., a Pentium class, a PowerPC processor, as well as other less 
powerful processors or processors developed specifically for small footprint devices. The processor 100 may 
have various clock speeds, including clock speeds similar to those found in desktop computer-class processors, as 
well as lower speeds such as 16 MHz. 

Also shown in Figure 1 the device includes a system memory 102. The system memory 102 may 
10 comprise memory of various types including RAM or ROM. A typical small footprint device may have a very 
small memory storage capacity compared to a typical desktop computer system. 

A small footprint device may also comprise one or more input mechanisms. An input mechanism 104 is 
illustrated in Figure 1. The input mechanism 104 may be any of various types, as appropriate to a particular 
device. For example, the input mechanism may be a keypad, mouse, trackball, touch pen, microphone, etc. 
15 A small footprint device may also comprise one or more display mechanisms. A display 106 is 

illustrated in Figure 1. However, a small footprint device may not comprise a display, or may comprise another 
type of output mechanism, such as an audio speaker. The display mechanism 106 may be any of various types, as 
appropriate to a particular device. The display mechanism for a typical small footprint device, such as a smart 
cellular phone, may be small compared to the display of a desktop computer system. 
20 Figure 2 - Hardware/Software Hierarchy Diagram 

Figure 2 illustrates a typical hierarchy of hardware/software layers involved in a system running 
applications and services within the containment framework. The drawing is exemplary, and various layers may 
be added, combined, or omitted as appropriate for a particular device or implementation. 

The base layer shown in Figure 2 is the device hardware layer 120, which comprises the hardware 
25 resources necessary to support a software system, such as a processor and system memory. In one embodiment, 
the hardware of a small footprint device, such as the small footprint device hardware example illustrated in Figure 
1, implements the hardware layer 120 illustrated in Figure 2. However, in other embodiments, the hardware layer 
120 may be implemented in other types of devices, such a device with even greater resource constraints than a 
typical small footprint device, such as a smart card. 
30 As shown in Figure 2, the next layer up from the hardware layer is the operating system layer 122. As is 

well known in the art, the operating system functions as an interface layer between the device hardware and 
software running on the device and serves as a manager for low-level tasks such as input/output, memory 
management, etc. The operating system 122 illustrated in Figure 2 may be any particular operating system which 
supports the higher layers shown in Figure 2. The operating system 122 may be a small and efficient one that is 
35 suitable for or written particularly for use in a small footprint device. For example, the operating system 122 may 
be the Java™OS operating system available from Sun Microsystems, Inc. 

In one embodiment, the containment framework is implemented in a Java™ application environment as 
one or more Java™ classes. As shown in Figure 2, the Java™ virtual machine layer 124 and Java™ application 
programming interface (API) class libraries layer 126 are the next layers up from the operating system. These 
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two layers together make up the Java™ application environment, or Java™ platform. Classes implementing the 
containment framework may be built using the Java™ libraries 126 and compiled into bytecodes. Hie bytecodes 
are instructions which execute on the Java™ virtual machine 124, which interacts with the operating system 122 
and/or the device hardware 120. 

5 In one embodiment, the containment framework is implemented in the PersonaUava Java™ application 

environment, which is a Java™ platform designed to be highly scalable, modular, and configurable, while 
requiring minimal system resources. PersonaUava™ comprises the Java™ virtual machine and a subset of the 
Java™ API, including core and optional APIs and class libraries. In addition, the PersonaUava™ API includes 
specific features required by consumer applications in resource-limited environments, such as a specialized 

10 version of the Java™ abstract window toolkit (AWT). The PersonaUava™ AWT library is targeted and tuned for 
consumer product look and feel, providing graphics and windowing features while supporting low-resolution 
displays and alternate input devices (via an extended event model for mouse- and keyboard-less devices). 

Referring again to Figure 2, the containment framework 128 is shown as the next layer up from the 
Java™ platform layer. As noted above, the containment framework 128 may also be based on other platforms. 

15 As described in detail below, the containment framework 128 manages program modules, e.g. by enabling 
module registration, lookup, instance tracking, etc. Modules may provide various services. The containment 
framework 128 enables modules to request other modules, in order to use their services. Applications may be 
implemented as modules that utilize the services of other modules. The containment framework 128 thus 
provides a lightweight, extendable service and application framework, enabling applications to coexist and share 

20 a modular code base. 

This type of extendable architecture enabling multiple program modules to cooperate is an important 
development for small footprint devices. Small footprint devices have historically been limited to relatively 
narrow uses. For example, cellular phones were typically used for telephony and little else. However, as various 
technologies are developed allowing small footprint devices to become "smarter", having general-purpose 

25 processors, larger display screens, etc., it has become desirable to expand the scope of applications used in small 
footprint devices. 

The present containment framework may enable the types of applications and services generally 
associated with desktop computing environments to work together in a small footprint device, in a manner that 
desktop computer users are familiar with. As illustrated in Figure 2 and described above, services and 

30 applications 130 running on a small footprint device may be implemented as modules built on the containment 
framework layer 128. For example, the Personal Applications suite available from Sun Microsystems, Inc. is 
built using one embodiment of the containment framework 128. The Personal Applications Suite comprises an 
integrated set of applications such as a browser, an email client, and a personal organizer. 

Figure 2 also illustrates the ability of some embodiments of the containment framework 128 to integrate 

35 off-device services 132 with on-device applications/services 130. For example, the containment framework 128 
may provide an interface between a small footprint device and a network such as a Jini™ network. A small 
footprint device system may register its services for use by other devices or clients in a network. The 
containment framework may also enable services and applications within the small footrpint device to look up 
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two layers together make up the Java™ application environment, or Java™ platform. Classes implementing the 
containment framework may be built using the Java™ libraries 126 and compiled into bytecodes. The bytecodes 
are instructions which execute on the Java™ virtual machine 124, which interacts with the operating system 122 
and/or the device hardware 120. 
5 In one embodiment, the containment framework is implemented in the PersonaUava Java™ application 

environment, which is a Java™ platform designed to be highly scalable, modular, and configurable, while 
requiring minimal system resources. PersonaUava™ comprises the Java™ virtual machine and a subset of the 
Java™ API, including core and optional APIs and class libraries. In addition, the PersonaUava™ API includes 
specific features required by consumer applications in resource-limited environments, such as a specialized 

1 0 version of the Java™ abstract window toolkit (A WO. The PersonaUava™ AWT library is targeted and tuned for 
consumer product look and feel, providing graphics and windowing features while supporting low-resolution 
displays and alternate input devices (via an extended event model for mouse- and keyboard-less devices). 

Referring again to Figure 2, the containment framework 128 is shown as the next layer up from the 
Java™ platform layer. As noted above, the containment framework 128 may also be based on other platforms. 

IS As described in detail below, the containment framework 128 manages program modules, e.g. by enabling 
module registration, lookup, instance tracking, etc. Modules may provide various services. The containment 
framework 128 enables modules to request other modules, in order to use their services. Applications may be 
implemented as modules that utilize the services of other modules. The containment framework 128 thus 
provides a lightweight, extendable service and application framework, enabling applications to coexist and share 

20 a modular code base. 

This type of extendable architecture enabling multiple program modules to cooperate is an important 
development for small footprint devices. Small footprint devices have historically been limited to relatively 
narrow uses. For example, cellular phones were typically used for telephony and little else. However, as various 
technologies are developed allowing small footprint devices to become "smarter", having general-purpose 

25 processors, larger display screens, etc., it has become desirable to expand the scope of applications used in small 
footprint devices. 

The present containment framework may enable the types of applications and services generally 
associated with desktop computing environments to work together in a small footprint device, in a manner that 
desktop computer users are familiar with. As illustrated in Figure 2 and described above, services and 

30 applications 130 running on a small footprint device may be implemented as modules built on the containment 
framework layer 128. For example, the Personal Applications suite available from Sun Microsystems, Inc. is 
built using one embodiment of the containment framework 128. The Personal Applications Suite comprises an 
integrated set of applications such as a browser, an email client, and a personal organizer. 

Figure 2 also illustrates the ability of some embodiments of the containment framework 128 to integrate 

35 off-device services 132 with on-device applications/services 130. For example, the containment framework 128 
may provide an interface between a small footprint device and a network such as a Jini™ network. A small 
footprint device system may register its services for use by other devices or clients in a network. The 
containment framework may also enable services and applications within the small footrpint device to look up 
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and use services provided by other network devices. The integration of services of the small footprint device with 
network services is discussed in more detail below for Figure 3. 
Figures 3-7: Exemplary Network Device and Service Federation 

Figure 3 illustrates an exemplary network in which a small footprint device running applications/services 
5 in the containment framework is connected to a local service-based network. In the example shown, a smart 
cellular phone 134 utilizing the containment framework 144 is connected to the network. Also shown attached to 
the network are a printer 130 and an internet-enabled television 132. In this example, it is assumed that the 
printer 130 and television 132 devices are operable to export services to a network and possibly use the services 
of other devices on the network. For example, the printer may export its print service 13S, and the internet 

10 television may look up the print service and use it to print a web page. To facilitate the federation of devices and 
services in this manner, a lookup service 136 is located on the network. The lookup service 136 may reside on a 
separate device such as a network server. 

The federation of devices and services may be implemented in various ways. For example, Jini™ 
technology, available from Sun Microsystems, Inc., comprises components and a programming model which 

15 enables the type of distributed system illustrated in Figure 3. In one embodiment, the local network shown in 
Figure 3 may be a Jini™ network, and the printer 130 and internet television 132 may be Jini™-enabied devices. 
Each device is operable to find the Jini™ network lookup service and register the services it offers with the 
lookup service. The lookup service maps interfaces indicating the functionality provided by a service to sets of 
objects that implement the service. 

20 To add its services to a service federation, a device or other service provider may first locate an 

appropriate lookup service by using a "discovery" protocol. Figure 4 illustrates the discovery process. As shown, 
the service provider 164, e.g. the printer 130 shown in Figure 3, may broadcast a request on the local network for 
any lookup services to identify themselves. 

Once the service provider 164 has located the lookup service 160, the service provider 164 may register 

25 its service with the lookup service 160 by using a "join" protocol. Figure 5 illustrates the join process. The 
service provider 164 may create a service object which clients can use to invoke the service. As illustrated in 
Figure 5, the service object for the provided services may then be loaded into the lookup service 160, along with 
service attributes or descriptors containing information about the types or names of services provided. For 
example, in a Jini™ network, the printer 130 shown in Figure 3 may create a service object which comprises a 

30 Java™ programming interface for the print service 138. The printer 130 may then call a "register" method of the 
lookup service 136, passing this service object, along with attributes which specify that the service 138 being 
registered is a print service, the printing resolution, the possible paper sizes, etc. 

Once the service provider 164 has joined its services with the lookup service 160, other network clients 
may request and use the services. The process of requesting a service, called lookup, is illustrated in Figure 6. 

35 After discovering the lookup service, a client 162 may request a service from the lookup service 160 using a 
description of the requested service. The lookup service 160 attempts to match the description given by the 
requestor to the services that have joined the lookup service. The lookup service 160 may use the service 
attributes sent by the service provider 164 during the join process to perform this matching. If a match is found, 
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and use services provided by other network devices. The integration of services of the small footprint device with 
network services is discussed in more detail below for Figure 3. 
Figures 3-7: Exemplary Network Device and Service Federation 

Figure 3 illustrates an exemplary network in which a small footprint device running applications/services 
5 in the containment framework is connected to a local service-based network. In the example shown, a smart 
cellular phone 134 utilizing the containment framework 144 is connected to the network. Also shown attached to 
the network are a printer 130 and an internet-enabled television 132. In this example, it is assumed that the 
printer 130 and television 132 devices are operable to export services to a network and possibly use the services 
of other devices on the network. For example, the printer may export its print service 138, and the internet 

10 television may look up the print service and use it to print a web page. To facilitate the federation of devices and 
services in this manner, a lookup service 136 is located on the network. The lookup service 136 may reside on a 
separate device such as a network server. 

The federation of devices and services may be implemented in various ways. For example, Jini™ 
technology, available from Sun Microsystems, Inc., comprises components and a programming model which 

15 enables the type of distributed system illustrated in Figure 3. In one embodiment, the local network shown in 
Figure 3 may be a Jini™ network, and the printer 130 and internet television 132 may be Jini™-enabled devices. 
Each device is operable to find the Jini™ network lookup service and register the services it offers with the 
lookup service. The lookup service maps interfaces indicating the functionality provided by a service to sets of 
objects that implement the service. 

20 To add its services to a service federation, a device or other service provider may first locate an 

appropriate lookup service by using a "discovery" protocol. Figure 4 illustrates the discovery process. As shown, 
the service provider 164, e.g. the printer 130 shown in Figure 3, may broadcast a request on the local network for 
any lookup services to identify themselves. 

Once the service provider 164 has located the lookup service 160, the service provider 164 may register 

25 its service with the lookup service 160 by using a "join" protocol. Figure 5 illustrates the join process. The 
service provider 164 may create a service object which clients can use to invoke the service. As illustrated in 
Figure 5, the service object for the provided services may then be loaded into the lookup service 160, along with 
service attributes or descriptors containing information about the types or names of services provided. For 
example, in a Jini™ network, the printer 130 shown in Figure 3 may create a service object which comprises a 

30 Java™ programming interface for the print service 138. The printer 130 may then call a "register" method of the 
lookup service 136, passing this service object, along with attributes which specify that the service 138 being 
registered is a print service, the printing resolution, the possible paper sizes, etc. 

Once the service provider 164 has joined its services with the lookup service 160, other network clients 
may request and use the services. The process of requesting a service, called lookup, is illustrated in Figure 6. 

35 After discovering the lookup service, a client 162 may request a service from the lookup service 160 using a 
description of the requested service. The lookup service 160 attempts to match the description given by the 
requestor to the services that have joined the lookup service. The lookup service 160 may use the service 
attributes sent by the service provider 164 during the join process to perform this matching. If a match is found, 
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the lookup service 160 provides the appropriate service object to the client 162. For example, a Java™ interface 
for the requested service may be provided to the client 162. 

Once a client 162 has received a service object from the lookup service, the client may invoke the 
service. Figure 7 illustrates the process of service invocation. When a service is invoked, the client 162 and the 
5 service provider 164 may communicate directly with each other. Any of various interaction protocols may be 
used for this communication. For example, the protocol used may be Java™ Remote Method Invocation (RMI), 
CORBA, DCOM, etc. The service object that a client receives from the lookup service may call back to code 
located at the service provider, e.g. by calling an RMI method, or it may execute locally to provide the requested 
service, or it may use a combination of these approaches. 
10 As shown in Figure 3, the lookup service 136 for a local network may also act as a gateway to an outside 

network such as the Internet 154. The service-based distributed computing model may thus be extended to 
include clients and services located outside the local network. For example, the technology being developed for 
the Open Service Gateway Initiative (OSGI) may be leveraged to implement this type of distributed computing 
system. 

15 This type of service sharing between and across different networks and the Internet may enable new 

types of applications to be developed. For example, merchants may use Internet services to record data about 
specific consumers, and advertising service providers may use this data to push context-specific ads onto 
consumer devices, depending on which local network the device is connected to, etc. For example, a customer 
may enter a shopping mall and connect a personal data assistant (PDA) into a local network for the shopping 

20 mall, via a wireless connection. An Internet-based consumer data service may be joined with the lookup service 
for the shopping mall network and may provide information about the specific consumer who has just plugged 
into the mall network. Services running in the shopping mall network may then use this data together with other 
factors such as the customer's current location within the mall, the time of day, etc., in order to generate 
personalized ads and push them onto the customer's PDA. 

25 Many other examples of services based on the network of Figure 3 are possible. For example: network- 

enabled consumer devices within a home may utilize a service provided by a power company, via the Internet, 
which manages power consumption within the home; security service providers may monitor a home or specific 
devices via network services and may notify the owner immediately when property is broken into; health service 
providers may remotely monitor a patient's state by communicating with medical instruments; etc. 

30 In the examples listed above, an assumption is made that devices are able to transparently connect to a 

network, integrate network services with device-resident services, and export device-resident services for use by 
network clients. The containment framework described herein may provide the necessary interface to integrate 
services and applications of small footprint devices such as personal data assistants, handheld computers, smart 
cellular phones, etc. with a network service federation. 

35 As shown in Figure 3 and described in more detail below, the containment framework 144 has its own 

type of lookup service 146. The lookup service 146 within the containment framework 144 may operate similarly 
to the local network lookup service described above, utilizing discovery, join, lookup, and service invocation 
processes. For example, the personal organizer application 152 may utilize various services such as a calendar 
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the lookup service 160 provides the appropriate service object to the client 162. For example, a Java™ interface 
for the requested service may be provided to the client 162. 

Once a client 162 has received a service object from the lookup service, the client may invoke the 
service. Figure 7 illustrates the process of service invocation. When a service is invoked, the client 162 and the 
5 service provider 164 may communicate directly with each other. Any of various interaction protocols may be 
used for this communication. For example, the protocol used may be Java™ Remote Method Invocation (RMI), 
CORBA, DCOM, etc. The service object that a client receives from the lookup service may call back to code 
located at the service provider, e.g. by calling an RMI method, or h may execute locally to provide the requested 
service, or it may use a combination of these approaches. 
10 As shown in Figure 3, the lookup service 1 36 for a local network may also act as a gateway to an outside 

network such as the Internet 154. The service-based distributed computing model may thus be extended to 
include clients and services located outside the local network. For example, the technology being developed for 
the Open Service Gateway Initiative (OSGI) may be leveraged to implement this type of distributed computing 
system. 

15 This type of service sharing between and across different networks and the Internet may enable new 

types of applications to be developed. For example, merchants may use Internet services to record data about 
specific consumers, and advertising service providers may use this data to push context-specific ads onto 
consumer devices, depending on which local network the device is connected to, etc. For example, a customer 
may enter a shopping mall and connect a personal data assistant (PDA) into a local network for the shopping 

20 mall, via a wireless connection. An Internet-based consumer data service may be joined with the lookup service 
for the shopping mall network and may provide information about the specific consumer who has just plugged 
into the mall network. Services running in the shopping mall network may men use this data together with other 
factors such as the customer's current location within the mall, the time of day, etc., in order to generate 
personalized ads and push them onto the customer's PDA. 

25 Many other examples of services based on the network of Figure 3 are possible. For example: network- 

enabled consumer devices within a home may utilize a service provided by a power company, via the Internet, 
which manages power consumption within the home; security service providers may monitor a home or specific 
devices via network services and may notify the owner immediately when property is broken into; health service 
providers may remotely monitor a patient's state by communicating with medical instruments; etc. 

30 In the examples listed above, an assumption is made that devices are able to transparently connect to a 

network, integrate network services with device-resident services, and export device-resident services for use by 
network clients. The containment framework described herein may provide the necessary interface to integrate 
services and applications of small footprint devices such as personal data assistants, handheld computers, smart 
cellular phones, etc. with a network service federation. 

35 As shown in Figure 3 and described in more detail below, the containment framework 144 has its own 

type of lookup service 146. The lookup service 146 within the containment framework 144 may operate similarly 
to the local network lookup service described above, utilizing discovery, join, lookup, and service invocation 
processes. For example, the personal organizer application 152 may utilize various services such as a calendar 
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service, a contact list service, a bookmark service, etc. (not shown). The personal organizer application 1S2 may 
obtain a reference for communicating with these services via the containment framework lookup service 146. 

The containment framework 144 may integrate its own lookup service 146 with an off-device lookup 
service such as the local network lookup service 136 shown in Figure 3. In this way, off-device services such as 
5 the print service 138 and the web service 140 may become available to the applications/services 148, 150, and 
152 of the containment framework, and vice versa. For example, the personal organizer application 152 may 
request a print service from the containment framework lookup service 146. The containment framework lookup 
service 146 may first search for an on-device print service. If one is not found, the containment framework 
lookup service 146 may then request a print service from the network lookup service 136. The service object for 

10 the print service 138 may then be returned to the personal organizer 152. An interface 142 between the on-device 
services/applications and the off-device services is illustrated in Figure 3. Details follow on how the integration 
of on-device/off-device services may be implemented. 

As noted above, clients of services may themselves be services to other clients. For example, the email 
client "application" 150 of the smart cellular phone shown in Figure 3 may itself be a service to a client running 

15 in the containment framework 144 or to a network client. For example, in the case of malfunction, the printer 130 
shown in Figure 3 may request an email service so that it can send diagnostic information to a service technician. 
If the network lookup service 136 cannot find a network-based email service, it may request an email service 
from the smart cellular phone 134 via the interface 142. A service object for the email application/service 150 
running in the containment framework 144 may be passed to the requesting printer client 130. In this example, 

20 the printer client 130 may communicate directly with the email application/service 150 to send an email 
containing diagnostic information to a printer service technician. The email application/service 150 may send the 
email immediately if it is able to find an email server service, or it may send the email later when such a service 
becomes available when the cellular phone user connects to a different network. 

Although the above description references specific protocols and programming models, such as Jini™ 

25 technology, it is noted that these specific technologies are exemplary only. For example, the applications and 
services within the containment framework may be integrated with clients, services, devices, networks, etc. which 
employ any of various types of standards, protocols, and programming models, including, but not limited to: 
Jini™, CORBA, COM/DCOM, Bluetooth, CAL, CEBus, HAVi, Home API, HomePNA, HomePnP, HomeRF, 
VESA, etc. 

30 Figure 8 - Containment Framework Block Diagram 

Figure 8 is an abstract block diagram illustrating the basic architecture of the containment framework 
environment As described above, the containment framework provides a containment system for applications 
and services. These applications and services are managed within the system as units called modules. The 
containment framework is lightweight; in one embodiment, modules may interact with a single framework 

35 manager object which performs all module management This manager is referred to herein as the central 
framework instance. In one embodiment, the central framework instance may be implemented as an instance of a 
Java™ class. Figure 8 illustrates the central framework instance 170 and the code and data it comprises/manages. 
It is noted that Figure 8 illustrates one embodiment of the containment framework. Other embodiments may 
employ a different architecture and/or may be implemented in different programming languages or software 
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service, a contact list service, a bookmark service, etc. (not shown). The personal organizer application 152 may 
obtain a reference for communicating with these services via the containment framework lookup service 146. 

The containment framework 144 may integrate its own lookup service 146 with an off-device lookup 
service such as the local network lookup service 136 shown in Figure 3. In this way, off-device services such as 
5 the print service 138 and the web service 140 may become available to the applications/services 148, 150, and 
152 of the containment framework, and vice versa. For example, the personal organizer application 152 may 
request a print service from the containment framework lookup service 146. The containment framework lookup 
service 146 may fust search for an on-device print service. If one is not found, the containment framework 
lookup service 146 may then request a print service from the network lookup service 136. The service object for 

10 the print service 138 may then be returned to the personal organizer 152. An interface 142 between the on-device 
services/applications and the off-device services is illustrated in Figure 3. Details follow on how the integration 
of on-device/off-device services may be implemented. 

As noted above, clients of services may themselves be services to other clients. For example, the email 
client "application" 150 of the smart cellular phone shown in Figure 3 may itself be a service to a client running 

15 in the containment framework 144 or to a network client For example, in the case of malfunction, the printer 130 
shown in Figure 3 may request an email service so mat it can send diagnostic information to a service technician. 
If the network lookup service 136 cannot find a network-based email service, it may request an email service 
from the smart cellular phone 134 via the interface 142. A service object for the email application/service 150 
running in the containment framework 144 may be passed to the requesting printer client 130. In this example, 

20 the printer client 130 may communicate directly with the email application/service 150 to send an email 
containing diagnostic information to a printer service technician. The email application/service 150 may send the 
email immediately if it is able to find an email server service, or it may send the email later when such a service 
becomes available when the cellular phone user connects to a different network. 

Although the above description references specific protocols and programming models, such as Jini™ 

25 technology, it is noted that these specific technologies are exemplary only. For example, the applications and 
services within the containment framework may be integrated with clients, services, devices, networks, etc. which 
employ any of various types of standards, protocols, and programming models, including, but not limited to: 
Jini™, CORBA, COM/DCOM, Bluetooth, CAL, CEBus, HAVi, Home API, HomeFNA, HomePnP, HomeRF, 
VESA, etc. 

30 Figure 8 - Containment Framework Block Diagram 

Figure 8 is an abstract block diagram illustrating the basic architecture of the containment framework 
environment As described above, the containment framework provides a containment system for applications 
and services. These applications and services are managed within the system as units called modules. The 
containment framework is lightweight; in one embodiment, modules may interact with a single framework 

35 manager object which performs all module management This manager is referred to herein as the central 
framework instance. In one embodiment, the central framework instance may be implemented as an instance of a 
Java™ class. Figure 8 illustrates the central framework instance 170 and the code and data it comprises/manages. 
It is noted that Figure 8 illustrates one embodiment of the containment framework. Other embodiments may 
employ a different architecture and/or may be implemented in different programming languages or software 
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environments. For example, the module management/containment performed by the central framework instance 
1 70 illustrated in Figure 8 may be performed by multiple objects or components in other embodiments. 

As shown in Figure 8, the central framework instance 170 comprises data 182 representing the modules 
currently loaded in the system. The containment framework architecture is non-hierarchical. Thus, the loaded 
5 modules may be represented as a flat list or array of modules. This non-hierarchical system helps to keep the core 
containment framework code and the modules running within the framework compact Systems employing 
hierarchical components such as JavaBeans™ components may provide associated benefits, but the benefits come 
at the expense of a more complex management system requiring more system resources. However, the 
containment framework does provide a mechanism for the non-hierarchical modules to gain many of the benefits 

10 of a hierarchical containment system. This mechanism is described below for Figures 9 and 10. 

As shown in Figure 8, in one embodiment the central framework instance 170 comprises publicly 
accessible methods 178 which modules may call. These methods may be broken into abstract groups. For 
example, one group of methods 172 may comprise lookup methods. Lookup methods implement the lookup 
service functionality described above. Modules may pass a module descriptor to a lookup method of the central 

IS framework instance 170 to locate a particular service module. The containment framework lookup process is 
described below for Figure 12. Another group of framework methods 174 may comprise methods for loading and 
unloading modules. After finding a service module, a client module may request the central framework instance 
170 to load the service module and return a reference to the loaded module. The client module may then invoke 
the service. The client may call a framework method to release the service module when it is finished using it 

20 Although described as distinct groups, the division of methods into lookup and load/unload groups may be only a 
conceptual division. For example, in one embodiment a lookup method may also load a module that it matches 
and return a reference to the matched module. 

Figure 8 also illustrates system data 180 referred to as framework metadata, which may comprise data 
182 describing the list of loaded modules and other data describing the state of the system. Another abstract 

25 group of methods 176 of the central framework instance 170 may comprise reflection methods. Reflection 
methods are somewhat different than the other groups of methods since they provide direct access to the core 
metadata 1 80. A special class of modules called system modules may call reflection methods to gain access to the 
metadata 180. Regular modules may not access the metadata 180. 

After receiving a reference to the core system data 1 80, a system module may use or modify the data in 

30 any way desirable. Thus, the containment framework is highly extendable. The central framework instance 170 
may itself remain small, and system modules may be added to implement any functionality not already enabled 
by the central framework instance 170. For example, a system module may enable the integration described 
above for Figures 3-7 between applications/services running within the containment framework and services 
based in an externa] network. 

35 In mis example, such a system module may be written as a secondary lookup service that conforms to 

the protocols and programming model of the external network. For example, for a Jini™ network, a system 
module may be written which discovers the Jini™ network lookup service and joins the network lookup service, 
registering itself as a secondary lookup service. When a network client requests a service, the network lookup 
service may invoke the lookup service implemented by the system module. This system module may attempt to 
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environments. For example, the module management/containment performed by the central framework instance 
170 illustrated in Figure 8 may be performed by multiple objects or components in other embodiments. 

As shown in Figure 8, the central framework instance 170 comprises data 182 representing the modules 
currently loaded in the system. The containment framework architecture is non-hierarchical. Thus, the loaded 
5 modules may be represented as a flat list or array of modules. This non-hierarchical system helps to keep the core 
containment framework code and the modules running within the framework compact Systems employing 
hierarchical components such as JavaBeans™ components may provide associated benefits, but the benefits come 
at the expense of a more complex management system requiring more system resources. However, the 
containment framework does provide a mechanism for the non-hierarchical modules to gain many of the benefits 

10 of a hierarchical containment system. This mechanism is described below for Figures 9 and 10. 

As shown in Figure 8, in one embodiment the central framework instance 170 comprises publicly 
accessible methods 178 which modules may call. These methods may be broken into abstract groups. For 
example, one group of methods 172 may comprise lookup methods. Lookup methods implement the lookup 
service functionality described above. Modules may pass a module descriptor to a lookup method of the central 

15 framework instance 170 to locate a particular service module. The containment framework lookup process is 
described below for Figure 12. Another group of framework methods 174 may comprise methods for loading and 
unloading modules. After finding a service module, a client module may request the central framework instance 
170 to load the service module and return a reference to the loaded module. The client module may then invoke 
the service. The client may call a framework method to release the service module when it is finished using it 

20 Although described as distinct groups, the division of methods into lookup and load/unload groups may be only a 
conceptual division. For example, in one embodiment a lookup method may also load a module that it matches 
and return a reference to the matched module. 

Figure 8 also illustrates system data 180 referred to as framework metadata, which may comprise data 
182 describing the list of loaded modules and other data describing the state of the system. Another abstract 

25 group of methods 176 of the central framework instance 170 may comprise reflection methods. Reflection 
methods are somewhat different than the other groups of methods since they provide direct access to the core 
metadata 1 80. A special class of modules called system modules may call reflection methods to gain access to the 
metadata 1 80. Regular modules may not access the metadata 180. 

After receiving a reference to the core system data 1 80, a system module may use or modify the data in 

30 any way desirable. Thus, the containment framework is highly extendable. The central framework instance 170 
may itself remain small, and system modules may be added to implement any functionality not already enabled 
by the central framework instance 170. For example, a system module may enable the integration described 
above for Figures 3-7 between applications/services running within the containment framework and services 
based in an external network. 

35 In this example, such a system module may be written as a secondary lookup service that conforms to 

the protocols and programming model of the external network. For example, for a Jini™ network, a system 
module may be written which discovers the Jini™ network lookup service and joins the network lookup service, 
registering itself as a secondary lookup service. When a network client requests a service, the network lookup 
service may invoke the lookup service implemented by the system module. This system module may attempt to 
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find a service module within the containment framework which matches the description of the requested service. 
If a match is found, then the system module may perform any necessary steps to export the service module to the 
network client, since the system module has full access to the system module list and metadata. For example, the 
system module may load and register the matched service module into the system and return an interface, such as 
5 a Java™ interface, to the newly loaded module to the requestor. 
Fi gures 9 and 10 - Simulating a Hierarchical Environment 

It is often desirable to establish a hierarchical context for modules. For example, several service 
modules of the same type may be present in a system, but each may behave slightly differently. In a hierarchical 
containment system, a request by a module for a service may be filtered through a parent or containing module of 

10 the requesting module so that a reference to a specific service module may be passed back to the requestor. 
Hierarchical containment also has other inherent advantages, such as an ability to easily distribute and store data 
among a hierarchy of modules. However, as stated above, a full implementation of a hierarchical containment 
system may be very costly in terms of the system resources required, such as memory and processing power. The 
containment framework may provide a mechanism giving developers and applications many of the benefits of 

IS hierarchical containment, but without the high overhead costs usually associated with it 

For example, one embodiment of the containment framework allows modules to register themselves as 
module request listeners of other modules. For example, a module A may register itself as a request listener of a 
module B, e.g., by calling an AddRequestListener method of the central framework instance. When module B 
subsequently calls a method of the central framework instance to find a particular service, the central framework 

20 instance checks for any module request listeners for module B. In this case, it finds module A as a request 
listener, and asks module A to provide the requested service module to module B. 

Figures 9 and 10 illustrate an exemplary use of module request listeners in the containment framework. 
Figure 9 illustrates a desired conceptual module hierarchy for print services. As shown in the figure, two print 
service modules 192 and 194, print service A and print service B, are encapsulated in a print manager module 

25 190. For example, the two print services 192 and 194 may print to different locations, have different resolution 
and color capabilities, etc. Either of these print service modules may satisfy a lookup request made by another 
module for a print service. However, it may be desirable to employ a print manager module which selects and 
returns a particular print service. For example the print manager 190 may select a print service based on which 
client module makes the print request, or the print manager may display a dialog box asking for user input for the 

30 desired print service characteristics. 

Although the containment framework utilizes a non-hierarchical containment model, the hierarchy 
illustrated in Figure 9 may be realized by registering the print manager module 190 as a module request listener 
of client modules that may request a print service. Figure 10 illustrates example modules 198 which may run in a 
system. As described earlier, these modules may themselves employ other modules as services. According to the 

35 non-hierarchical model of the containment framework, the modules are shown arranged in a flat layout, with no 
inherent module hierarchy. 

In this example, the web browser module 196 may be operable to make a print request, e.g., for printing 
a web page. As shown in Figure 10, the print manager module 190 may be registered as a module request listener 
for the web browser module 196. Upon receiving the print service request from the web browser 196, the 
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find a service module within the containment framework which matches the description of the requested service. 
If a match is found, then the system module may perform any necessary steps to export the service module to the 
network client, since the system module has full access to the system module list and metadata. For example, the 
system module may load and register the matched service module into the system and return an interface, such as 
5 a Java™ interface, to the newly loaded module to the requestor. 
Fi gures 9 andlO - Simulating a Hierarchical Environment 

It is often desirable to establish a hierarchical context for modules. For example, several service 
modules of the same type may be present in a system, but each may behave slightly differently. In a hierarchical 
containment system, a request by a module for a service may be filtered through a parent or containing module of 

10 the requesting module so that a reference to a specific service module may be passed back to the requestor. 
Hierarchical containment also has other inherent advantages, such as an ability to easily distribute and store data 
among a hierarchy of modules. However, as stated above, a full implementation of a hierarchical containment 
system may be very costly in terms of the system resources required, such as memory and processing power. The 
containment framework may provide a mechanism giving developers and applications many of the benefits of 

1 5 hierarchical containment, but without the high overhead costs usually associated with it 

For example, one embodiment of the containment framework allows modules to register themselves as 
module request listeners of other modules. For example, a module A may register itself as a request listener of a 
module B, e.g., by calling an AddRequestListener method of the central framework instance. When module B 
subsequently calls a method of the central framework instance to find a particular service, the central framework 

20 instance checks for any module request listeners for module B. In this case, it finds module A as a request 
listener, and asks module A to provide the requested service module to module B. 

Figures 9 and 10 illustrate an exemplary use of module request listeners in the containment framework. 
Figure 9 illustrates a desired conceptual module hierarchy for print services. As shown in the figure, two print 
service modules 192 and 194, print service A and print service B, are encapsulated in a print manager module 

25 190. For example, the two print services 192 and 194 may print to different locations, have different resolution 
and color capabilities, etc. Either of these print service modules may satisfy a lookup request made by another 
module for a print service. However, it may be desirable to employ a print manager module which selects and 
returns a particular print service. For example the print manager 190 may select a print service based on which 
client module makes the print request, or the print manager may display a dialog box asking for user input for the 

30 desired print service characteristics. 

Although the containment framework utilizes a non-hierarchical containment model, the hierarchy 
illustrated in Figure 9 may be realized by registering the print manager module 190 as a module request listener 
of client modules that may request a print service. Figure 10 illustrates example modules 198 which may run in a 
system. As described earlier, these modules may themselves employ other modules as services. According to the 

35 non-hierarchical model of the containment framework, the modules are shown arranged in a flat layout, with no 
inherent module hierarchy. 

In this example, the web browser module 196 may be operable to make a print request, e.g., for printing 
a web page. As shown in Figure 10, the print manager module 190 may be registered as a module request listener 
for the web browser module 196. Upon receiving the print service request from the web browser 196, the 
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containment framework lookup service may find the print manager module 190 registered as a request listener for 
the web browser module 196 and may ask the print manager module 190 to provide a print service module to the 
web browser requestor 196. The print manager module 190 may then return a reference to print service module 
A 192 or print service module B 194, or the print manager module 190 may present a dialog box to the user to 
5 decide which print service module to return, etc. Thus, the desired module hierarchy of Figure 9 may be 
implemented for non-hierarchical modules of the containment framework. 
Figure 1 1 - Parcel Packaging Units 

Modules may be packaged into units referred to as parcels. This packaging serves several purposes. For 
example, parcels provide a convenient mechanism to manage related code and data as a unit If closely related 

10 modules have static dependencies, then they may be packaged together into a parcel. Parcels may be used to 
handle installation and upgrading within a system. 

Figure 11 illustrates an example parcel 200 that groups together modules related to a personal 
information manager (PIM). The figure shows a calendar module 202, a contact list module 204, an appointment 
module 208, and a user interface module 206. Various other modules may be present in the parcel as desired. 

15 The modules of the PIM parcel 200 may also make use of various core service modules running within the 
containment framework, such as bookmark services, find services, etc. The use of a PIM parcel may simplify 
installation and upgrading of a PIM application. Packaging the PIM modules into a parcel in this way also has the 
development-time benefit of creating separate code units for multi-target development. 

Parcels also provide an additional way to provide a run-time context for non-hierarchical modules. 

20 When a module is loaded into the system, the central framework instance may store metadata specifying which 
parcel, if any, the module belongs to. Service modules may later use this information to provide services 
differently for different client modules, depending on which parcel the client belongs to. For example, client 
modules may use a file access service module to obtain a root directory. The file access module may return 
different root directories for different clients, depending on which parcels the clients belong to. 

25 Figure 12 - Module Request Flowchart Diagram 

Figure 12 is a flowchart diagram illustrating a typical lookup process that the central framework instance 
may perform when it receives a lookup request for a service module from a client module. It is noted that Figure 
12 is exemplary and mat various steps may be combined, omitted, or modified. For example, as noted previously, 
system modules may be added which customize the lookup process. 

30 In step 300 of Figure 12, the central framework instance receives a module lookup request from a 

requestor module. For example, the requestor module may call a RequestModule method of the central 
framework instance, passing a module descriptor for the service module being requested, as well as a reference to 
the requestor module itself. The reference to the requestor module may be added to the system data so to keep 
track of service module users. As described in more detail below, a module may be unloaded when no other 

35 modules are using it 

The module descriptor passed by the requestor module specifies various attributes about the requested 
module that the framework instance can use to attempt to find a matching module. This module descriptor may 
be an object which comprises information such as the requested module's service type, class name, and/or 
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containment framework lookup service may find the print manager module 190 registered as a request listener for 
the web browser module 196 and may ask the print manager module 190 to provide a print service module to the 
web browser requestor 196. The print manager module 190 may then return a reference to print service module 
A 192 or print service module B 194, or the print manager module 190 may present a dialog box to the user to 
5 decide which print service module to return, etc. Thus, the desired module hierarchy of Figure 9 may be 
implemented for non-hierarchical modules of the containment framework. 
Figure 1 1 - Parcel Packaging Units 

Modules may be packaged into units referred to as parcels. This packaging serves several purposes. For 
example, parcels provide a convenient mechanism to manage related code and data as a unit If closely related 
10 modules have static dependencies, then they may be packaged together into a parcel. Parcels may be used to 
handle installation and upgrading within a system. 

Figure 11 illustrates an example parcel 200 that groups together modules related to a personal 
information manager (PIM). The figure shows a calendar module 202, a contact list module 204, an appointment 
module 208, and a user interface module 206. Various other modules may be present in the parcel as desired. 
15 The modules of the PIM parcel 200 may also make use of various core service modules running within the 
containment framework, such as bookmark services, find services, etc. The use of a PIM parcel may simplify 
installation and upgrading of a PIM application. Packaging the PIM modules into a parcel in this way also has the 
development-time benefit of creating separate code units for multi-target development. 

Parcels also provide an additional way to provide a run-time context for non-hierarchical modules. 
20 When a module is loaded into the system, the central framework instance may store metadata specifying which 
parcel, if any, the module belongs to. Service modules may later use this information to provide services 
differently for different client modules, depending on which parcel the client belongs to. For example, client 
modules may use a file access service module to obtain a root directory. The file access module may return 
different root directories for different clients, depending on which parcels the clients belong to. 
25 Figure 12 - Module Request Flowchart Diagram 

Figure 12 is a flowchart diagram illustrating a typical lookup process that the central framework instance 
may perform when it receives a lookup request for a service module from a client module. It is noted that Figure 
12 is exemplary and mat various steps may be combined, omitted, or modified. For example, as noted previously, 
system modules may be added which customize the lookup process. 
30 In step 300 of Figure 12, the central framework instance receives a module lookup request from a 

requestor module. For example, the requestor module may call a RequestModule method of the central 
framework instance, passing a module descriptor for the service module being requested, as well as a reference to 
the requestor module itself. The reference to the requestor module may be added to the system data so to keep 
track of service module users. As described in more detail below, a module may be unloaded when no other 
35 modules are using it 

The module descriptor passed by the requestor module specifies various attributes about the requested 
module that the framework instance can use to attempt to find a matching module. This module descriptor may 
be an object which comprises information such as the requested module's service type, class name, and/or 
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service-specific attributes, etc. The requestor may also pass a text description to the central framework instance, 
which the central framework instance may use to create a module descriptor object 

In step 302, the central framework instance checks to see whether any request listener modules are 
registered for the requesting module. If a request listener is found, then in step 304 the framework instance 
5 notifies the request listener of the request and instructs the request listener to attempt to provide a module which 
matches the module request descriptor. If the request listener can provide a matching module, then execution 
proceeds to step 314. Otherwise, other registered request listeners may be asked to provide a module, until a 
match is found or there are no more request listeners. 

If no request listeners are found, or if no request listeners can provide the requested module, execution 

10 proceeds to step 306. However, in one embodiment, if one or more request listeners are registered for the 
requesting module, and none of mem are able to provide a matching module, then execution may stop after step 
304. In step 306, the central framework instance checks the list of modules to determine whether one of the 
modules matches the module descriptor. If a match is found, then in step 308 the framework instance checks 
whether the matched module is multi-instantiable. If not, then execution proceeds to step 3 14. 

15 if the matched module is found to be multi-instantiable in step 308, then the central framework instance 

may continue to search through the module list for a match. If there are no more modules to search, execution 
proceeds to step 310. In step 310, the framework instance searches for module-provider modules in the module 
list. Module-provider modules are modules capable of providing a requested module. For example, a network 
lookup service may be imported as a module-provider module for the containment framework. 

20 If a module-provider module is found, then in step 312, the central framework instance notifies the 

module-provider module of the request and instructs it to attempt to provide a module which matches the module 
request descriptor. If a match is found then execution proceeds to step 314. If the module provider cannot 
provide the requested module, the central framework instance may search for other module-provider modules and 
repeat step 312. If no module providers are present in the module list or if none can provide the requested 

25 module, then the requestor is notified that the request cannot be fulfilled, and execution completes. 

Step 314 may be reached from step 304, 308, or 312. In all cases, a module is found which matches the 
module request descriptor. In step 314 the requestor is registered as a user of the matched module, and in step 
316 a reference to the matched module is returned to the requestor. Any necessary initialization steps involved in 
loading and initializing the matched module are also performed in step 314. For example, modules may have an 

30 Initialize method that is called when a module is loaded. 

As noted above, the flowchart of Figure 12 is exemplary, and various embodiments may have different 
lookup/load scenarios. For example, a module may call a central framework method to load a service module 
without returning a reference to the matched module, or request listeners may be ignored in some cases, etc. 
Figure 13 - Module Release Flowchart Diagram 

35 When a client module is finished using a service module, the client may call a method of the central 

framework instance to release the module. Figure 13 is a flowchart diagram illustrating the module release 
process. The flowchart of Figure 13 is exemplary, and various steps may be combined, omitted, added, or 
modified as required or desired for different embodiments. 
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service-specific attributes, etc. The requestor may also pass a text description to the central framework instance, 
which the central framework instance may use to create a module descriptor object 

In step 302, the central framework instance checks to see whether any request listener modules are 
registered for the requesting module. If a request listener is found, then in step 304 the framework instance 
5 notifies the request listener of the request and instructs the request listener to attempt to provide a module which 
matches the module request descriptor. If the request listener can provide a matching module, then execution 
proceeds to step 314. Otherwise, other registered request listeners may be asked to provide a module, until a 
match is found or there are no more request listeners. 

If no request listeners are found, or if no request listeners can provide the requested module, execution 

10 proceeds to step 306. However, in one embodiment, if one or more request listeners are registered for the 
requesting module, and none of them are able to provide a matching module, then execution may stop after step 
304. In step 306, the central framework instance checks the list of modules to determine whether one of the 
modules matches the module descriptor. If a match is found, then in step 308 the framework instance checks 
whether the matched module is multi-instantiable. If not, then execution proceeds to step 3 14. 

15 if the matched module is found to be multi-instantiable in step 308, then the central framework instance 

may continue to search through the module list for a match. If there are no more modules to search, execution 
proceeds to step 310. In step 310, the framework instance searches for module-provider modules in the module 
list. Module-provider modules are modules capable of providing a requested module. For example, a network 
lookup service may be imported as a module-provider module for the containment framework. 

20 If a module-provider module is found, then in step 312, the central framework instance notifies the 

module-provider module of the request and instructs it to attempt to provide a module which matches the module 
request descriptor. If a match is found then execution proceeds to step 314. If the module provider cannot 
provide the requested module, the central framework instance may search for other module-provider modules and 
repeat step 312. If no module providers are present in the module list or if none can provide the requested 

25 module, then the requestor is notified that the request cannot be fulfilled, and execution completes. 

Step 314 may be reached from step 304, 308, or 312. In all cases, a module is found which matches the 
module request descriptor. In step 314 the requestor is registered as a user of the matched module, and in step 
316 a reference to the matched module is returned to the requestor. Any necessary initialization steps involved in 
loading and initializing the matched module are also performed in step 314. For example, modules may have an 

30 Initialize method that is called when a module is loaded. 

As noted above, the flowchart of Figure 12 is exemplary, and various embodiments may have different 
lookup/load scenarios. For example, a module may call a central framework method to load a service module 
without returning a reference to the matched module, or request listeners may be ignored in some cases, etc. 
Figure 13 - Module Release Flowchart Diagram 

35 When a client module is finished using a service module, the client may call a method of the central 

framework instance to release the module. Figure 13 is a flowchart diagram illustrating the module release 
process. The flowchart of Figure 13 is exemplary, and various steps may be combined, omitted, added, or 
modified as required or desired for different embodiments. 
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In step 330, the central framework instance receives a module-release notice from a user module. As 
described above for Figure 12, when a user module requests a service module, the user module is added to a list 
of users of the service module. In step 332, the central framework instance removes the releasing user module 
from the list of users of the released module. In step 334, the framework instance determines whether any other 
user modules are using the released module, e.g., by checking whether other modules are present in the releases 
module's user module list If so, then execution stops. 

If no other modules are using the released module, the central framework instance may attempt to unload 
the released module. In step 336, the framework instance may call a CanFinalize method of the released module. 
The CanFinalize method returns true if the module can be unloaded, or false otherwise. If the CanFinalize 
method returns false in step 336, then execution stops. Otherwise, a Finalize method of the released module may 
be called. The Finalize method may perform any necessary steps for unloading the module, such as releasing 
resources. The module may then be unloaded, which may involve garbage-collection, etc., depending on the 
particular embodiment 

Although the present invention has been described in connection with specific embodiments, it is not 
intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such 
alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the 
invention as defined by the appended claims. 
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In step 330, the central framework instance receives a module-release notice from a user module. As 
described above for Figure 12, when a user module requests a service module, the user module is added to a list 
of users of the service module. In step 332, the central framework instance removes the releasing user module 
from the list of users of the released module. In step 334, the framework instance determines whether any other 
5 user modules are using the released module, e.g., by checking whether other modules are present in the releases 
module's user module list If so, then execution stops. 

If no other modules are using the released module, the central framework instance may attempt to unload 
the released module. In step 336, the framework instance may call a CanFinalize method of the released module. 
The CanFinalize method returns true if the module can be unloaded, or false otherwise. If the CanFinalize 
10 method returns false in step 336, then execution stops. Otherwise, a Finalize method of the released module may 
be called. The Finalize method may perform any necessary steps for unloading the module, such as releasing 
resources. The module may then be unloaded, which may involve garbage-collection, etc., depending on the 
particular embodiment 

Although the present invention has been described in connection with specific embodiments, it is not 
IS intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such 
alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the 
invention as defined by the appended claims. 
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WHAT IS CLAIMED IS: 

1. A software framework for a small footprint device, wherein said framework supports shareable 
program modules, wherein said program modules are executable to implement computing services. 

5 2. The software framework of claim 1 , wherein said small footprint device comprises an operating 

system, and wherein said small footprint device further comprises an executable software environment enabling 
software programs to execute within said software environment, and wherein the software framework comprises a 
software component which executes within said software environment 

10 3. The software framework of claim 2, wherein said executable software environment is a Java™ 

Application Environment 

4. The software framework of claim 3, wherein said software component is an instance of a Java™ 

class. 

15 

5. The software framework of claim 2, wherein said software component is operable to load said 
program modules into said software environment. 

6. The software framework of claim 2, wherein a first program module is loaded into said software 
20 environment, wherein said first program module is operable to request said software component to load a second 

program module into said software environment, wherein said software component is operable to load said 
second program module into said software environment in response to receiving said request from said first 
program module. 

25 7. The software framework of claim 6, wherein said software component is further operable to 

return to said first program module a reference to said second program module, wherein said first program 
module is operable to invoke said second program module. 

8. The software framework of claim 2, wherein a first program module is loaded into said software 
30 environment, wherein said first program module is operable to pass a module descriptor to said software 

component, wherein said software component is operable to locate a second program module matching said 
module descriptor and load said second program module into said software environment 

9. The software framework of claim 2, wherein a first program module is loaded into said software 
35 environment, wherein said first program module is operable to pass a module descriptor to said software 

component, wherein said software component is operable to locate a second program module matching said 
module descriptor and return to said first program module a reference to said second program module. 
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10. The software framework of claim 2, wherein a first program module and a second program 
module are loaded into said software environment, and wherein said second program module is operable to 
request from said software component a reference to a third program module, and wherein said software 
component is operable to instruct said second program module to return to said first program module a request to 

5 said third program module. 

1 1. The software framework of claim 1, wherein the software framework comprises a means for a 
first program module to register as a module request listener for a second program module, wherein said first 
program module is operable to receive a request from said second program module for a reference to a third 

10 program module which matches a module descriptor, and wherein said first program module is operable to return 
to said second program module a reference to a third program module matching said module descriptor. 

12. The software framework of claim 1, wherein the software framework comprises data regarding 
said program modules, and wherein said program modules comprise system modules of a first class which are 

IS able to access all of said data, and wherein said program modules further comprise modules of a second class 
which are unable to access at least a portion of said data. 

13. The software framework of claim 1, wherein a first program module runs within the software 
framework, wherein said first program module is executable to implement a first computing service, and wherein 

20 a second program module runs within the software framework, wherein said second program module is 
executable to implement a second computing service, and wherein said second program module utilizes said first 
program module to implement said second computing service. 

14. The software framework of claim 13, wherein said second computing service is a web browsing 
25 service, wherein said web browsing service enables a user of said small footprint device to view web pages. 

15. The software framework of claim 1, wherein said small footprint device comprises system 
memory, and wherein the software framework comprises one or more software components, and wherein said one 
or more software components are stored in said system memory, and wherein said one or more software 

30 components require less than 300 kilobytes of memory space. 

16. The software framework of claim 1, wherein said small footprint device is a small footprint 
device from the group consisting of: personal data assistant (PDA), cellular phone, and global positioning system 
(GPS) receiver. 

35 

17. The software framework of claim 1, wherein said small footprint device is a small footprint 
device from the group consisting of: game console, wearable computing device, set-top box, and electronic book 
device. 
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framework, wherein said first program module is executable to implement a fust computing service, and wherein 

20 a second program module runs within the software framework, wherein said second program module is 
executable to implement a second computing service, and wherein said second program module utilizes said first 
program module to implement said second computing service. 

14. The software framework of claim 13, wherein said second computing service is a web browsing 
25 service, wherein said web browsing service enables a user of said small footprint device to view web pages. 

15. The software framework of claim 1, wherein said small footprint device comprises system 
memory, and wherein the software framework comprises one or more software components, and wherein said one 
or more software components are stored in said system memory, and wherein said one or more software 

30 components require less than 300 kilobytes of memory space. 

16. The software framework of claim 1, wherein said small footprint device is a small footprint 
device from the group consisting of: personal data assistant (PDA), cellular phone, and global positioning system 
(GPS) receiver. 

35 

17. The software framework of claim 1, wherein said small footprint device is a small footprint 
device from the group consisting of: game console, wearable computing device, set-top box, and electronic book 
device. 
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18. The software framework of claim 1, wherein said small footprint device comprises less than 2 
megabytes of memory. 

19. The software framework of claim 1, wherein said small footprint device comprises a display 
5 screen smaller than twenty square inches. 

20. The software framework of claim 1, wherein said small footprint device is exclusively battery 
operated. 

10 21. A small footprint device operable to run program modules, wherein said small footprint device 

comprises: 

a processing unit; 
a system memory; 

wherein said system memory stores an operating system and an executable software environment 
1 5 enabling software programs to execute within said software environment; 

wherein said system memory also stores one or more software components according to the present 
invention, wherein said one or more software components execute within said software environment and wherein 
said one or more software components implement a software framework supporting shareable program modules, 
wherein said program modules are executable to implement computing services. 

20 

22. The small footprint device of claim 21, wherein said executable software environment is a 
Java™ Application Environment 

23. The small footprint device of claim 21, wherein one or more of said software components are 
25 operable to load said program modules into said software environment 

24. The small footprint device of claim 21, wherein a first program module is loaded into said 
software environment, wherein said first program module is operable to request one or more of said software 
components to load a second program module into said software environment, wherein said one or more of said 

30 software components are operable to load said second program module into said software environment in 
response to receiving said request from said first program module. 

25. The small footprint device of claim 24, wherein said one or more of said software components 
are further operable to return to said first program module a reference to said second program module, wherein 

35 said first program module is operable to invoke said second program module. 

26. The small footprint device of claim 21, wherein said software framework comprises data 
regarding said program modules, and wherein said program modules comprise system modules of a first class 
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18. The software framework of claim 1, wherein said small footprint device comprises less than 2 
megabytes of memory. 
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5 screen smaller than twenty square inches. 
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Java™ Application Environment. 
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24. The small footprint device of claim 21, wherein a first program module is loaded into said 
software environment, wherein said first program module is operable to request one or more of said software 
components to load a second program module into said software environment, wherein said one or more of said 

30 software components are operable to load said second program module into said software environment in 
response to receiving said request from said first program module. 

25. The small footprint device of claim 24, wherein said one or more of said software components 
are further operable to return to said first program module a reference to said second program module, wherein 

35 said first program module is operable to invoke said second program module. 

26. The small footprint device of claim 21, wherein said software framework comprises data 
regarding said program modules, and wherein said program modules comprise system modules of a first class 
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which are able to access all of said data, and wherein said program modules further comprise modules of a second 
class which are unable to access at least a portion of said data. 

27. The small footprint device of claim 21, wherein said small footprint device is a small footprint 
device from the group consisting of: personal data assistant (PDA), cellular phone, and global positioning system 
(GPS) receiver. 

28. The small footprint device of claim 21, wherein said small footprint device is 8 small footprint 
device from the group consisting of: game console, wearable computing device, set-top box, and electronic book 
device. 

29. The small footprint device of claim 21, wherein said system memory has a storage capacity of 
less than 2 megabytes. 

30. The software framework of claim 21, wherein said small footprint device is exclusively battery 
operated. 
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which are able to access all of said data, and wherein said program modules further comprise modules of a second 
class which are unable to access at least a portion of said data. 

27. The small footprint device of claim 21, wherein said small footprint device is a small footprint 
device from the group consisting of: personal data assistant (PDA), cellular phone, and global positioning system 
(GPS) receiver. 

28. The small footprint device of claim 21, wherein said small footprint device is a small footprint 
device from the group consisting of: game console, wearable computing device, set-top box, and electronic book 
device. 

29. The small footprint device of claim 21, wherein said system memory has a storage capacity of 
less than 2 megabytes. 

30. The software framework of claim 21, wherein said small footprint device is exclusively battery 
operated. 
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